The interconnected nature of today's global businesses demands continuous availability of database data. Database downtime affects performance of applications that may interact with database systems, as well as the human performance that depends on those database systems. For example, taking down database systems sustaining online banking web services will affect a user's ability to access their bank accounts and also affect customer service satisfaction. In fact, many database users have high availability requirements, such as 99.999% uptime (which means a maximum downtime per year of 5.26 minutes).
Database reconfiguration is one reason that database data becomes unavailable. During database reconfiguration, new lock requests are temporarily stalled, causing the users of the database to experience a brownout. Database reconfiguration can be required for many reasons, including a new server node joining a cluster of nodes, one or more servers of the cluster getting shut down for maintenance or due to software or hardware failures, etc.
Database reconfiguration is generally implemented by freezing access to the database and scanning every lock being maintained for the database (which may be on the order of a billion locks), since any one of the locks might be affected by the reconfiguration. Scanning every lock maintained for a database is time-consuming and, as such, database reconfiguration can bring a database offline for an unacceptable amount of time. Therefore, it would be beneficial to minimize the amount of time that is needed for database reconfiguration.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.